1. Field of the Invention
This invention relates generally to computer software. More particularly, the invention relates to the persistent storage of object-oriented components.
2. Description of the Related Art
There are many benefits associated with modularity and object-oriented programming paradigms in software designs. One such benefit is the use of reusable components. JavaBeans.TM. is one example of an object-oriented, software component model. Reusable components such as JavaBeans.TM. can be used as building blocks in composing applications. For example, a builder tool could be used to connect together and customize a set of JavaBeans.TM. components to act as an application. In this example, JavaBeans.TM. could include GUI elements such as windows and buttons that can be nested inside one another in an object graph. Reusable components can also be used more like stand-alone applications. For example, a JavaBean.TM. which implements a spreadsheet could be embedded in a web page or in another suitable container.
In any reusable component system, it is important to provide storage of components in a persistent form. When the reusable components are implemented in an object-oriented language, persistent storage can be achieved through serialization: a process of transforming one or more objects from a run-time or transient form to a persistent form. In other words, serialization is a process of recording the state of an object graph in such a way that the object graph can be reconstituted at a later time. Serialization is applicable not only to reusable components, but to any objects.
One approach to serialization, the default object serialization provided by the Java.TM. Language, flattens a graph of objects into a byte stream by taking a "snapshot" of memory. The byte stream can then be stored in one or more persistent containers such as files. Subsequently, the byte stream can be reconstituted into live Java.TM. Language objects through the process of deserialization. This approach, however, has many drawbacks. The snapshot of the live object graph is linked to the internal implementation of classes rather than to the public APIs of classes. This approach also produces a large amount of data to store. Furthermore, the data produced by this approach is in a binary format which cannot be edited manually using a standard text editor.
Another approach is to serialize an object graph in a textual format which is readable and editable by hand. For example, this approach could be implemented as shown in the following high-level pseudo-code, wherein the serialization output text generated by write() is based on Java.TM. Language source code:
writeObject(Object node) { PA1 }
nodeName=&lt;generate a symbol&gt; PA2 write(nodeName+"=new "+node.class +"().backslash.n"); PA2 for each property p in node.class.properties do { PA2 } PA2 return name;
write(nodeName+"."+p.name+"="+ PA4 writeObject(p.value(node))+".backslash.n");
The approaches described above store all values, even default values, for objects. When many values of a object are default values, as is often the case, then huge amounts space are effectively wasted.
Another approach to serialization is to save space in the serialized file by storing meta-data which specifies default values of classes. In systems such as Delphi and Visual Basic, however, this approach is implemented only for primitive values, and not for value types that comprise objects. Furthermore, this approach is error-prone in that it leaves default information in two places: in the serialized meta-data and in the constructor.
Therefore, it is desirable to provide an improved system and method for serializing an object graph.